CASTLE Framework for Productivity/Workplace Applications CASTLE 框架：為提升工作效率的應用設計

摘要：

HEART 框架適用於消費者產品，但對於使用者無法選擇是否使用的工作類應用（如企業軟體、政府工具等）效果有限。為此，CASTLE 框架應運而生，專門為內部團隊設計，以滿足工作場景下的使用者體驗需求。

HEART 框架的侷限性

谷歌開發的HEART 框架，常用於評估使用者體驗，它涵蓋了五個主要方面：快樂感（Happiness）、參與度（Engagement）、使用率（Adoption）、留存率（Retention）和任務成功率（Task success）。這個框架靈活且易於理解，但它更適合那些使用者可以自由選擇的消費類產品。當我們使用 HEART 框架來衡量企業內部軟體或工作應用時，很多指標不再適用。比如，留存率對於工作軟體來說意義不大，因為使用者無法決定是否使用這個軟體，它通常是工作要求的一部分。

雖然我們可以對 HEART 框架進行一些調整，比如用“使用率”來衡量員工發現某個高階功能的頻率，但它缺乏針對工作效率軟體的敏感度。為此，我們提出了一套專門用於評估工作類應用的框架：CASTLE框架。

CASTLE 框架：適用於工作類軟體的 UX 評估工具

CASTLE是六個重要維度的縮寫：

這些維度涵蓋了工作效率應用中最關鍵的使用者體驗因素，幫助我們更全面地評估使用者在使用強制性工作軟體時的感受和表現。

如何分解各個維度：目標、訊號和衡量標準

像 HEART 框架一樣，CASTLE 框架中的每個維度都是廣泛的概念，無法直接量化。我們需要將其分解成可衡量的具體指標。透過定義高層次的目標（Goals），識別表現這些目標的使用者行為（Signals），再進一步將這些行為轉化為量化指標（Measures），我們可以追蹤每個維度的表現。

以下是每個維度的具體說明和示例：

1. 認知負荷（Cognitive Load）

認知負荷指的是使用者在完成任務時需要投入的腦力。這包括他們在處理流程時的記憶負擔，比如頻繁跳轉頁面的操作會增加使用者的認知負荷。此外，處理大量無關的資訊（如過多的警報）或需要自己進行心算和資料轉換，都會加重認知負擔。

示例：

目標：通知不頻繁且不會打擾使用者。

訊號：使用者自述的心理負擔有所減少。

衡量標準：使用 NASA-TLX 問卷調查使用者的心理負擔。

2. 高階功能使用率（Advanced Feature Usage）

很多企業軟體都會包含一些高階功能，但實際使用這些功能的使用者往往少得可憐。這個維度衡量的是使用者是否使用了那些雖然不是必需但能提升效率的功能，比如個性化設定或加速工具。

示例：

目標：資訊面板能展示對使用者有用的個性化資訊。

訊號：使用者根據個人偏好自定義了面板。

衡量標準：透過分析記錄自定義面板的使用者比例及常見的自定義選項。

3. 滿意度（Satisfaction）

滿意度衡量的是使用者對軟體的整體感受。工作類軟體的目標通常不是讓使用者感到“驚喜”，而是讓他們在工作中儘量減少挫敗感和不滿。滿意度可以透過問卷調查、任務後的反饋或分析“憤怒點選”（使用者頻繁點選某個元素表達不滿）等方式來衡量。

示例：

目標：使用者對產品感到滿意。

訊號：使用者的自述滿意度提升。

衡量標準：使用 SEQ 問卷測量使用者滿意度。

4. 任務效率（Task Efficiency）

任務效率指的是使用者完成工作流程所需的時間和步驟數。透過分析完成任務的步驟數或使用者在流程中的時間，可以幫助最佳化使用者體驗。

示例：

目標：使用者能快速完成主要任務。

訊號：使用者在流程中不會被分心，任務完成速度加快。

衡量標準：使用定量的可用性測試，測量完成任務所需的時間。

5. 學習性（Learnability）

學習性衡量的是新使用者學習並掌握軟體的難易程度。提升學習性可以幫助新員工更快適應工作，並減少他們對幫助檔案的依賴。

示例：

目標：使用者能記住完成工作流程的步驟。

訊號：使用者的任務表現隨著時間的推移有所提升。

衡量標準：透過長期的可用性測試，測量任務完成時間的變化。

6. 錯誤率（Errors）

這個維度衡量的是使用者在操作過程中出現的錯誤，既包括使用者操作失誤，也包括系統出現的錯誤提示。跟蹤錯誤資訊和錯誤頻率有助於發現並修復使用者在使用軟體時遇到的問題。

示例：

目標：使用者輸入的資料更準確。

訊號：使用者輸入的數值未超出合理範圍。

衡量標準：透過分析系統的驗證錯誤日誌。

總結與建議

CASTLE 框架不是用來取代 HEART 框架的，而是作為一種補充，特別適合評估工作效率類應用中的使用者體驗。在實際操作中，不必追蹤所有維度，可以根據具體情況選擇最重要的指標。此外，量化指標只能告訴我們問題的表象，想要找到問題的根本原因，還需要結合定性研究，比如使用者訪談和可用性測試。